容器開創了虛擬化的新時代。當容器數量不多時，其實只要寫幾個腳本，就能達到管理的效果；但如果是一間大企業，內部有數百甚至數千個容器，就會發現，單靠腳本管理容器的方式逐漸變得難以維護，也更容易出錯。

為了解決大規模容器管理的挑戰，Google 在 2014 年開源了容器管理平台 Kubernetes（簡稱 K8S），大幅降低了管理大量容器的難度。不過，使用 K8S 時也有許多安全問題需要留意；若設定不當，攻擊者便可能入侵叢集，甚至進一步控制底層主機。今天，就讓我們一起探討容器化環境中的重要角色—K8S。

K8S 的架構：

先來看看官方提供的 K8S 架構圖：

Cluster Architecture

簡單介紹一下各個元件的職責：

• Control Plane：由 API server、etcd、scheduler 與 controller-manager 等元件組成，負責管理叢集的整體狀態。這些元件可以部署在一台或多台主機上。
• Node：可以是實體機或虛擬機。負責承載應用程式工作負載的節點通常稱為 Worker Node（工作節點），透過 kubelet 與容器執行環境執行 Pod。
• Pod：K8S 中可建立與管理的最小部署單位。一個 Pod 可以包含一個或多個容器；單一容器是最常見的使用方式，多容器則適合需要緊密協作的情境。
• kubelet：在各節點上執行的代理程式，依據 Pod 的設定，透過容器執行環境管理容器，並向 API server 回報 Pod 與節點的狀態。
• kube-proxy：維護節點上的網路規則，讓送往 Service 的流量能轉送至對應的後端 Pod。
• etcd：以鍵值（key-value）形式儲存叢集的設定與狀態資料。
• scheduler：負責選擇適合的 Worker Node，並將 Pod 指派給該 Node。
• API server：提供 Kubernetes API，讓使用者與叢集元件查詢、建立及修改叢集資源。
• controller-manager：執行多個控制器，持續協調叢集，讓實際狀態接近期望設定。

看過 K8S 的架構後，接著，簡單看看 Day 20～Day 25 將介紹的主題。

接下來幾篇文章使用的靶機環境如下：

受限於篇幅，這個系列會先聚焦在幾個常見的 K8S 攻擊面，其他主題將在鐵人賽結束後另文補充。
感謝大家今天的收看，我們明天見！